Publish and Subscribe is an effective way of disseminating information to multiple users. Publish/Subscribe applications can help to enormously simplify the task of getting business messages and transactions to a wide, dynamic and potentially large audience in a timely manner.
In a publish/subscribe messaging system subscribers register their interest in one or more topics. The broker performs a match of publications to interested subscribers and sends a copy of each publication to the appropriate subscribers. The stream of publication messages is divided into a sequence of packets of sizes that are optimal for the transmission medium being used. To maximise the efficiency of the network utilisation in such a publish/subscribe system it is preferable to multicast the packets that contain the messages which are to be sent to a number of subscribers. Where there is a large number of subscribers for a given topic the network efficiency gain provided by multicast is greater. The broker performs the role of multicast transmitter and the subscribers each perform the role of multicast receiver.
In a reliable multicast publish/subscribe system, subscribers request retransmission of any packet that is not delivered. They do this by detecting gaps in the delivery sequence. When a subscriber detects a missing packet it requests retransmission by sending a “negative acknowledgement” or NACK. To avoid the generation of a storm of NACKs when a packet goes missing, the subscribers can use a NACK suppression mechanism, which operates by each subscriber setting a random back-off timer and sending a multicast NACK packet on expiry of the timer. If a subscriber sees another subscriber's NACK packet before its own timer expires, it cancels the timer.
However, this approach has the disadvantage(s) that the only feedback that the broker has is the receipt of NACK packets when one or more subscribers fail to receive a packet and the notification during orderly subscriber termination that a subscriber no longer wishes to receive publications matching a particular set of topics. The broker has no guarantee that either of these forms of feedback will be received; no packets may be being dropped and subscribers could fail or disconnect unintentionally. Accordingly, the broker has no knowledge of the current status of the subscribers and is therefore obliged to keep multicasting publications even when no subscribers are actually running, thus reducing the efficiency of such a system.
A need therefore exists for efficient liveness monitoring in a reliable multicast system wherein the abovementioned disadvantage(s) may be alleviated.